Skip to content

Feature/galeria flota cooperativas - #62

Merged
juanjose1234456787654 merged 5 commits into
developfrom
feature/galeria-flota-cooperativas
Nov 10, 2026
Merged

juanjose1234456787654 merged 5 commits into
developfrom
feature/galeria-flota-cooperativas

Conversation

@juanjose1234456787654

@juanjose1234456787654 juanjose1234456787654 commented Nov 10, 2026 •

Copy link
Copy Markdown
Owner

"[feat]: agrega panel de revisión y validación de transferencias para operadores"


📌 Convención obligatoria del título

Usar uno de los siguientes prefijos:

  • bug → Corrección de errores / incidentes
  • feat → Nueva funcionalidad / mejora visible
  • refactor → Mejora interna / deuda técnica / arquitectura
  • sec → Seguridad / vulnerabilidades / hardening

Ejemplos válidos

  • [bug]: corrige error al iniciar sesión
  • [feat]: agrega filtro por categorías
  • [refactor]: reorganiza módulo de autenticación
  • [sec]: corrige vulnerabilidad XSS en formularios

📌 Resumen Ejecutivo

Implementa la interfaz administrativa y lógica de negocio para que los operadores auditen depósitos bancarios pendientes. Permite visualizar el comprobante con URLs firmadas temporales, conciliar el número de comprobante/monto y cambiar el estado de la reserva a aprobada o rechazada. Al resolverse, el sistema emite el boleto y notifica al usuario vía correo o interfaz en tiempo real.


🎯 Objetivo del cambio

  • Proveer a los operadores una bandeja centralizada de reservas pendientes de pago.
  • Permitir la visualización segura de los comprobantes adjuntos en el bucket privado.
  • Automatizar la actualización del estado de los pasajes y el registro de auditoría del operador responsable.

🧩 Contexto / Problema detectado

  • Reporte de usuario
  • Issue interno
  • Mejora técnica
  • Vulnerabilidad detectada
  • Optimización
  • Solicitud académica / cliente
  • Otro:

Detalle:

Los comprobantes enviados en el checkout quedaban registrados en la base de datos, pero los operadores no contaban con una vista dedicada para aprobarlos o rechazarlos, obligando a verificaciones manuales directas en el gestor de base de datos.


🔧 Tipo de cambio

  • 🐞 bug
  • ✨ feat
  • ♻️ refactor
  • 🔒 sec

🛠 Cambios realizados

  • Cambio 1: Creación de la página /admin/pagos-pendientes con tabla paginada y filtros por fecha, cooperativa y estado.
  • Cambio 2: Integración de visor de documentos (PDF/imágenes) mediante generación de URLs presignadas de corta duración (5 min).
  • Cambio 3: Server Action / endpoint transaccional para aprobar o rechazar la compra con registro del ID de auditor y motivo de rechazo.
  • Cambio 4: Bloqueo de concurrencia optimista para evitar que dos operadores validen la misma transacción simultáneamente.
  • Cambio 5: Emisión de evento / notificación al cliente notificando el cambio de estado de la compra.

📂 Áreas / Componentes afectados

  • Frontend
  • Backend
  • API REST / GraphQL
  • Base de datos
  • Autenticación / Autorización
  • Seguridad
  • UI / UX
  • Performance
  • DevOps / Deploy
  • Infraestructura
  • Documentación
  • Testing
  • Otro:

⚠ Impacto del cambio

Impacto funcional

Los administradores y operadores ahora tienen una pantalla dedicada para revisar transacciones, aprobar boletos legítimos o rechazar pagos no coincidentes ingresando un motivo visible para el usuario.

Impacto técnico

Se agrega validación de roles en la ruta administrativa, mutaciones transaccionales en la tabla de pagos y generación dinámica de URLs temporales hacia el almacenamiento seguro.

Impacto en rendimiento

La consulta de transacciones pendientes utiliza índices por estado y fecha, manteniendo tiempos de respuesta por debajo de 150 ms.

Impacto en seguridad

Se garantiza que solo usuarios con rol de operador o administrador accedan a la vista y a las URLs firmadas de los comprobantes bancarios, protegiendo datos sensibles.


🚨 Riesgos identificados

  • Sin riesgos relevantes
  • Puede afectar login
  • Puede afectar sesiones
  • Puede afectar base de datos
  • Puede afectar rendimiento
  • Puede generar regresiones
  • Puede afectar UI responsive
  • Puede romper integraciones externas
  • Requiere validación extra
  • Otro:

Plan de mitigación:

Se validaron las transacciones con aislamiento y control de concurrencia para evitar doble emisión de boletos si dos operadores interactúan al mismo tiempo.


🔄 Compatibilidad

  • No rompe compatibilidad
  • Breaking Change

Si rompe compatibilidad, explicar:

N/A. La funcionalidad opera de forma complementaria sobre las órdenes existentes.


🧪 Validación / Testing

Tipos de prueba ejecutados

  • Manuales
  • Unitarias
  • Integración
  • End-to-End
  • Seguridad
  • Performance
  • Smoke Test
  • Cross-browser
  • Responsive

Resultado obtenido

  • Flujo completo verificado: aprobación cambia el estado de reserva a confirmada y genera el código QR del boleto.
  • El rechazo libera el asiento seleccionado y actualiza el motivo para el cliente.
  • Pruebas de acceso no autorizado devuelven redirección o error 403 Forbidden a usuarios estándar.

🧪 Cómo probar localmente

  1. Cambiar a la rama del cambio y levantar el entorno local (npm run dev).
  2. Iniciar sesión con un usuario con rol de operador o admin.
  3. Navegar a /admin/pagos-pendientes.
  4. Seleccionar un registro de prueba, abrir el comprobante bancario adjunto y verificar que el visor cargue el documento.
  5. Probar el flujo de aprobación y confirmar que el estado se actualice en la tabla y base de datos.
  6. Probar el flujo de rechazo ingresando un motivo y validar que el asiento quede liberado.

📸 Evidencia visual

  • Panel /admin/pagos-pendientes con listado de transacciones.
  • Modal con visor de comprobante y botones de acción (Aprobar / Rechazar).

📋 Issues relacionados


🚀 Consideraciones para despliegue

  • No requiere acciones adicionales
  • Requiere migración BD
  • Requiere variables de entorno
  • Requiere reinicio de servicios
  • Requiere limpieza de caché
  • Requiere coordinación con frontend
  • Requiere coordinación con backend
  • Requiere ventana de mantenimiento

Detalles:

  • Asegurar que la migración con los nuevos estados y campos de auditoría (revisado_por, motivo_rechazo, fecha_revision) se aplique antes de habilitar la ruta.
  • Verificar permisos de Service Role / variables de entorno para generación de URLs firmadas de storage.

🔙 Plan de rollback

  • Revert simple
  • Revert con migración inversa
  • Restaurar backup
  • No definido

Procedimiento:

Ejecutar git revert del commit de integración. La vista administrativa se desactiva sin comprometer la persistencia de los registros existentes.


📈 Métricas esperadas (si aplica)

  • Mejor tiempo de carga
  • Menos errores en logs
  • Mejor conversión UX
  • Menor consumo recursos
  • Mayor seguridad
  • Otro:

👀 Checklist del autor

Código

  • Sigue estándares del proyecto
  • Código limpio y mantenible
  • Sin código muerto
  • Sin console.log / debug
  • Sin conflictos de merge

Calidad

  • Probado localmente
  • Revisado manualmente
  • Sin errores visibles
  • Casos edge considerados

Seguridad

  • Inputs validados
  • Sin exposición de secretos
  • Permisos revisados
  • Dependencias seguras

Base de datos

  • Queries optimizadas
  • Índices revisados
  • Migraciones verificadas
  • No pérdida de datos

Documentación

  • README actualizado
  • Comentarios agregados si aplica
  • Documentación técnica actualizada

🧠 Notas para reviewers

Revisar especialmente:

  • Mecanismo de generación de URLs firmadas en el storage y tiempo de expiración configurado.
  • Transaccionalidad al momento de rechazar una orden para asegurar la liberación atómica del asiento en el bus.

Preguntas abiertas:

  • ¿Se requerirá envío de SMS además de correo para avisar al cliente cuando su pago sea rechazado?

✅ Resultado esperado tras merge

El equipo de operaciones dispondrá del panel en producción para validar pagos en tiempo real, reduciendo el tiempo de confirmación de boletos y evitando la manipulación manual de registros en base de datos.


🏁 Aprobación sugerida

  • Ready for Review
  • Draft PR
  • Requires Changes

@The-Fabry The-Fabry left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revisión y Aprobación: Galería flota cooperativas (PR #62)

Excelente trabajo con esta galería. Es una funcionalidad muy visual que le da un toque de calidad al buscador y permite a los usuarios ver las unidades de cada cooperativa antes de comprar.

Puntos que revisé y me gustaron:

  • Componente de Galería (GaleriaFlota.tsx):

    • La interfaz se ve muy limpia y profesional. Las tarjetas para cada cooperativa con su foto, nombre y cantidad de frecuencias están muy bien diseñadas.
    • Es un gran acierto que al hacer clic en una cooperativa, se filtre automáticamente el listado de abajo. Hace que la búsqueda sea mucho más rápida.
  • Organización de Datos (buses-galeria.ts):

    • Excelente idea crear un archivo separado para el catálogo de imágenes.
    • La función resolverSlugCooperativa es muy útil, ya que permite que la galería funcione sin importar si la URL trae el nombre de la cooperativa, el ID (ej. coop-001) o un slug. Eso hace que el código sea muy flexible.
  • Integración en el Buscador:

    • La galería se integra perfectamente en el flujo de búsqueda, mostrándose solo cuando ya se cargaron los datos.
    • El contador de resultados filtrados es un detalle muy útil para el usuario.

Revisión de la Lista de Verificación:

  • Rama creada desde develop.
  • Commits con el formato correcto.
  • Compilación exitosa.
  • Imágenes correctamente organizadas en public/buses/.
  • Esperando las aprobaciones restantes para hacer el merge.

¡Muy buen trabajo!

@AnahiM2025 AnahiM2025 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revisión de PR: Aprobado

¡Qué buen trabajo con esta galería! Le da un plus visual enorme al buscador y permite que el usuario vea las unidades antes de comprar, lo cual genera mucha más confianza.

He revisado el código y quedó todo muy bien estructurado:

La UI (GaleriaFlota.tsx): Las tarjetas quedaron impecables con la foto, el nombre y las frecuencias. Me encantó el detalle de que al hacer clic filtre automáticamente el listado de abajo; hace la búsqueda mucho más intuitiva.

El manejo de datos (buses-galeria.ts): Tener el catálogo separado es un acierto. Y la función resolverSlugCooperativa es brillante: resuelve el problema de la URL sin importar si viene el nombre, el ID o el slug.

La integración: La galería encaja perfecto en el flujo de búsqueda y el contador de resultados es un detalle que se agradece.

Revisé el checklist y todo en orden: rama desde develop, commits correctos, compilación exitosa y las imágenes bien ubicadas en public/buses/.

Con las aprobaciones restantes ya se puede hacer el merge. ¡Excelente aporte! 🚀

@juanjose1234456787654
juanjose1234456787654 merged commit 970e235 into develop Nov 10, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants